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(54) Tide: AUTOMOBILE INFORMATION SYSTEM 



(57) Abstract 

An automobile information system facilitates communication within clusters of components and among various clusters. Each cluster 
has logically related automobile components (e.g., environment control components, entertainment components, etc.) interconnected to a 
cluster controller connected via a data communications bus. The cluster controller is responsible with disseminating information received 
from an external source and exchanging information between two or more components. The cluster controller is implemented as a 
general-purpose computing device having an open platform operating system, which supports multiple applications and provides interfaces 
to the components. The cluster controllers are interconnected via another data communications bus to enable information flow between 
clusters. In this manner, any component in one cluster can share information with any component in another cluster without need for 
dedicated wiring or specially written code. 
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A T rTOMOBTLF, INFORMATION SYSTEM 
TECHNICAL FIELD 

This invention relates to information systems for automobiles 
5 BACKGROUND OF TTTF, INVENTION 

In traditional automotive electronic systems, dedicated components are employed 
to control specific functions in the vehicle. These dedicated components are typically 
independent of one another, each with its own operator interface. For instance, most 
modem automobiles have an electronic engine control system, a computerized antilock 

10 braking system (ABS), a vehicle safety system, a lighting control system, a climate 
control subsystem, and a sound system. Most vehicles also have power door locks, power 
windows, and power seating for the operator's comfort. 

Some automobile models are equipped with a navigation system that employs a 
global positioning system (GPS) receiver to receive positioning signals from a satellite 

15 network. The navigation system computes coordinates that locate the vehicle over the 
surface of the earth with regard to longitude, latitude, and altitude. Cellular 
communication systems have also been introduced into automobiles to enable the driver 
or occupant to transact telephone calls from their vehicle. Most late model automobiles 
are also constructed with a diagnostic system that analyzes the performance of the 

20 automobile engine, air and heating system, and other components (1 996 or later for OBD 
II, 1993 or later for OBD I). 

While these various electronic control units have proven useful, there is a 
drawback in that all of them are entirely separate and independent from one another. 
Generally, different manufacturers supply these subsystems. These disparate components 

25 often employ proprietary, dedicated processors or ASICs (application specific integrated 
circuits) that have different system architectures and execute incompatible proprietary 
software. The components have limited or no communications with one another. 
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Yet, today's automotive electronic systems increasingly encompass a broader 
range of functionality, such as task management, resource management, communication 
with other control units or systems, time-critical monitoring and control of equipment. 
This requires increased integration of components into networks of distributed and 
5 multiplexed electronic system, as well as interfaces for communication between the 
control units and for communication with the operator. The motivations for this 
increased integration of the automotive electronic system are many, including: 



• Cost reduction of existing functions; 

1 0 • Cost effective improvement of existing functions; 

• Cost effective enabling of new functions; 

• Reduction of wiring weight; 

• Simplify addition of new functions via software upgrade; 

• Optimization of electronic and mechanical integration; 

15 • Increase of system performance, intelligence, and coherent; and 

• Increase data communications with external systems/infrastructure. 



Some strides have been made to integrate the components. Typically, the 
proposals call for each of the distributed components to be connected to a data bus, such 

20 as a CAN (Controller Area Network) protocol bus. Designers have theorized different 
multiplexing protocols and token passing protocols to facilitate communication over the 
bus. For more information on these proposals, the reader is directed to the following 
articles which appear in a publication from the Society of Automotive Engineers (SAE): 
Inoue et al., "Multiplex Systems for Automotive Integrated Control," Multiplex 

25 Technology Applications in V ehicle Electrical Systems. SP-954, No. 930002, copyright 
1993; Azuma et al., "Development of a Class C Multiplex Control IC," Multiplex 
Technology Applications in Vehicle Electrical Systems. SP-954, No. 930003, copyright 
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1993; Mathony et al. "Network Architecture for CAN" Multiplex Technology 

A pplications in Vehicle Elec trical Systems. SP-954, No. 930004, copyright 1993; 

Szydolowski, "A Gateway for CAN Specification 2.0 Non-Passive Devices," Multiplex 

Technology Applications in V ehicle Electrical Systems. SP-954, No. 930005, copyright 
5 1993; Neumann et al., "Open Systems and Interfaces for Distributed Electronics in Cars 

(OSEK)," Automotive Mu ltiplexing Technology. SP-1070, No. 950291, copyright 1995; 

and Emaus, "Aspects and Issues of Multiple Vehicle Networks," Automotive 

Multi plexing Technology . SP-1070, No. 950293, copyright 1995. 

While there has been some progress at interconnecting electronic components in a 
10 distributed system via a communication link, there is no commonly accepted standard for 

the main vehicle system bus and bus interface. Achieving the above objectives entails a 

system design that is flexible and scaleable, with the capability to manage complex 

functions. 

15 SUMMARY OF THE INVENTION 

This invention concerns an automobile information system that facilitates 
communication within clusters of components and among various clusters. Each cluster 
has a controller that provides a platform for supporting many diverse components. 

In one implementation, various automobile components are grouped into logical 
20 clusters. For example, components used to control an operator's environment in the 
automobile (e.g., climate control, lighting, seat position, window placement, door locks, 
etc.) might form a first cluster. Another cluster might contain components related to 
entertainment and communication functions (e.g., audio, navigation, cellular 
communications, etc.). 

25 Each cluster has its own cluster controller to manage information flow among the 

cluster's components. A data communications bus interconnects the cluster controller 
and components. The cluster controller is responsible with disseminating information 
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received from external sources to the various components with interest in the information 

as well as exchanging information between two or more components within the cluster. 

Each cluster controller is implemented, for example, as a general-purpose 

computing device having an open platform operating system. The operating system 
5 offers a platform with APIs (application program interfaces) and DDIs (device driver 

interfaces) that allow developers to interface different peripheral components with a 

common controller. The cluster controller supports multiple applications and provides 

interfaces for those programs to the hardware peripheral devices. 

The cluster controllers are interconnected via another data communications bus to enable 
10 information flow between clusters. In this manner, any component in one cluster can 

share information with any component in another cluster without need for dedicated 

wiring or specially written code. 

Tf pnr.F INSCRIPTION OF THE DRA WINGS 
15 The same reference numerals are used throughout the drawings to reference like 

components and features. 

Fig. 1 is a diagrammatic illustration of a vehicle information and control system 

implemented in an automobile. 

Fig. 2 is a block diagram of a cluster having a cluster controller to manage 

20 information flow among multiple components. 

Fig. 3 is a block diagram of two clusters, with the cluster controllers 

interconnected to one another. 

Fig. 4 is a block diagram of a cluster controller. 

Fig. 5 is a block diagram of software architecture employed in the cluster 
25 controller. 
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n y.TATT.F.n nFsrwTPTTON OF THE PREFERRED EMBODIMENT 
General System 

Fig. 1 shows vehicle information system 20 constructed in an automobile 22. The 
automobile control system 20 has a master control unit (MCU) 24 and one or more 
5 secondary control unit (SCU) 26(1) and 26(2). A dual bus structure having a primary 
data communications bus 28 and a secondary support bus 30 provide an infrastructure for 
data communications in the control system 20. The primary bus 28 may be implemented 
using any vehicle bus design currently employed or contemplated by automobile 
manufactures, such as CAN, ABUS, VAN, J1850, K-BUS, P-BUS, I-BUS, USB, P1394, 
10 and so forth. The master control unit 24 can be configured as master of the primary bus 
28. The support bus 30 may be implemented as any standard computer data bus, such as 
PCI, USB, P1394, and the like. One or both secondary control units 26(1) and 26(2) can 
be configured as master of the support bus 30 and as controller of one or more 
components coupled to the support bus 30. 
15 The master control unit 24 and the secondary control unit(s) 26 are interconnected 

through the primary vehicle bus 28. In addition, various electronic automobile 
components are connected to the master control unit 24 via the primary bus 28. In this 
illustration, the electronic components include an antilock braking system (ABS) 32, an 
electronic steering system 34, and an engine control system 36. However, other 
20 components may likewise be connected to the primary vehicle bus 28, such as a 
security/alarm system, a diagnostic system, a lighting control system, a fuel injection 
system, an automatic transmission system, and so forth. In addition, the electronic 
components shown in Fig. 1 are intelligent components in that they each have their own 
local controller, typically embodied as a microprocessor. The automobile might further 
25 include non-intelligent electronic components that do not have local processing 
capabilities. 
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Fig. 1 shows a number of devices connected to the support bus 30. These devices 
include a climate control system 38, an audio system 40, a navigation system 42 with 
global positioning system (GPS) antenna 44, and a cellular communications system 46. 
The support bus 30 is also coupled to a wipers module 48, lighting control 50, power door 

5 locks 52, power window controls 54, and seat control 56. An SCU 26 may also be 
configured as a server to serve to multiple clients 58. The clients 58 can be implemented, 
for example, as small hand held or laptop game computers having visual display screens 
and audio sound cards to provide multimedia entertainment. The SCU 26 serves in-car 
entertainment in the form of movies and games to the clients 58 for the passengers' 

10 enjoyment. 

The control units 24 and 26 can be arranged in two different architectures: (1) 
master/slave architecture; and (2) cluster architecture. In a master/slave architecture, the 
master control unit 24 acts as the master of the primary vehicle bus 28 and all electronic 
components 32-36, as well as the secondary control unit(s) 26, act as slaves to master 

15 control unit 24. The master control unit 24 manages data flow among the electronic 
components 32-36 and facilitates resource and information sharing. In addition, the 
master control unit 24 provides backup for the intelligent electronic components in the 
event that any of them fail, and also performs data processing and control functions for 
non-intelligent electronic components. This architecture is described in detail in U.S. 

20 Patent Application 08/771,343, entitled "Fault-Resilient Automobile Control System", 

which was filed December 16, 1996, and issued as U.S. Patent No. on 

. This patent is assigned to Microsoft Corporation and is incorporated by 

reference. 

25 Cluster Architecture 

In a cluster architecture, the control units 24 and 26 (or the two secondary control 
units 26(1) and 26(2)) act as cluster controllers to control groups of related components. 
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For example, a cluster controller might provide control of lights, climate control system 
(heating, ventilation and air conditioning), windshield wipers, seat adjustments. Another 
cluster controller may provide more advanced features, such as access to vehicle 
diagnostic information, intelligent door lock, remote alarm/unlocking, and configurable 

5 instrument panel and head-up display. With a cluster controller, the functionality of the 
core subsystems can be greatly enhanced by sharing hardware resources and information 
among the components and subsystems. It also provides maximum flexibility and allows 
additional functionality to be added as new components to the system without having to 
redesign the entire system. 

10 Fig. 2 shows an exemplary cluster architecture 60 in which one of the secondary 

control units 26(1) is configured as a cluster controller for the wipers module 48, lighting 
control module 50, door lock modules 52, power window control modules 54, and a seat 
control module 56. The cluster controller 26(1) facilitates information sharing among the 
cluster of components over bus 30. For example, suppose the vehicle operator sets the 

15 vehicle alarm system when exiting the vehicle. The vehicle alarm system informs the 
cluster controller 26 that the alarm is now activated. When the cluster controller 26 
receives this notification, this single piece of information is shared among the 
components so that those components with interest may take some sort of action. Here, 
the lighting control module 50 may blink the interior lights to provide feedback to the 

20 operator that the alarm has been set. Concurrently, the door lock modules 52 and power 
window controls 54 are toggled to a locked state to prevent unwanted entry. 

With the cluster architecture, multiple clusters can be interconnected via one or 
more data buses to communicate with each other. Communication between clusters 
enables increased functionality of the system and helps reduce cost, simplify information 

25 communication, and optimize functions. 

In traditional prior art systems, dedicated wiring is required for one component to 
communicate with another component. Consider the example of adding a feature of 
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remote locking and unlocking of the vehicle doors via telephone or email. To perform 
this task, the traditional solution is to add wiring between the door lock control module 52 
and communication module 46 to form a dedicated communication link. Then, special 
software is written to enable the communication module 46 to receive the instruction to 
5 lock the door and to send that instruction to the door look control module 52. Moreover, 
one or both of the modules needs to be adapted to communicate according to a specific 
protocol employed by the other. 

In the clustering architecture, however, the communication link between the 
cluster controllers handles the communication between various components without need 

10 of special wiring or programming. Fig. 3 shows a cluster architecture 62 in which two 
clusters 64 and 66 are interfaced together. The first cluster 64 is the same as that shown 
in Fig. 2, with cluster controller 26(1) controlling the components related to the vehicle 
operating environment (e.g., wipers 48, door locks 52 and seat control module 56). The 
fust cluster controller 26(1) interfaces with these components via bus 30. 

15 A second cluster controller 26(2) controls the second cluster 66, which groups 

communication and entertainment functions. In this example, the second cluster 
controller 26(2) facilitates communication and information flow among the audio module 
40, the navigation component 42, and cellular communications module 46. The second 
cluster also utilizes the bus 30, although a separate bus may be used. 

20 The first and second cluster controllers 26(1) and 26(2) are connected via bus 28. 

The cluster controllers 26(1) and 26(2) facilitate communication flow between any 
component in the first cluster 64 and any component in the second cluster 66 over the 
second bus 28. The two cluster controllers 26(1) and 26(2) can utilize a common 
communications protocol to communicate over bus 28, thereby eliminating the need for 

25 one peripheral device to be specially programmed to communicate with another 
peripheral device. Furthermore, no dedicated wiring is required. 
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Consider again the example of adding a feature of remote locking and unlocking of 
the vehicle doors via telephone or email. Here, an operator can send a command to lock 
the vehicle doors using email or a cell phone and the command is received at the cellular 
communications module 46 (or its cluster controller 26(2) and passed to the 

5 communications module 46). The communications module 46 then transmits a signal 
destined to the door module 52 over bus 30 to its cluster controller 26(2), which in turn 
transmits the signal over bus 28 to cluster controller 26(1). The signal is then delivered 
over bus 30 to the door module 52. 

It is noted that although the implementation illustrated in Fig. 3 utilizes the same 

10 secondary bus 30 to facilitate information flow within the clusters, separate and distinct 
buses may be employed within the various clusters. Furthermore, since the clusters are 
implemented using a single platform (described below in more detail), additional 
software modules can be easily added to the system to perform the desired function, i.e., 
locking or unlocking the vehicle via phone or email. 

15 

Cluster Controller 

Fig. 4 shows an exemplary implementation of a cluster controller. In this 
illustration, the cluster controller is implemented as a secondary control unit 26, which is 
embodied as a general-purpose computer with an open platform operating system capable 
20 of supporting multiple applications. The master control unit 24 can be configured in a 
very similar manner. 

The cluster controller 26 has a processor 100, volatile memory 102 (e.g., RAM), 
and non-volatile memory 104 (e.g., ROM, Flash, hard disk, etc.). The cluster controller 
26 has a primary bus interface 106 to provide access to the primary vehicle bus 28 and a 
25 support bus interface 108 to provide access to the support bus 30. 

The cluster controller 26 runs an open platform operating system 1 10 that supports 
multiple applications. With an open platform operating system, the cluster controller 26 
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can support a wide variety of software applications and hardware peripherals on the 
support bus 30. The operating system is preferably a real-time, multitasking operating 
system that is capable of supporting "plug-and-play" system configuration and providing 
high stability, security, and efficiency. One preferred operating system is a "Windows" 

5 brand operating system sold by Microsoft Corporation, such as "Windows CE", 
"Windows NT", or other derivative versions of "Windows". A multitasking operating 
system allows simultaneous execution of multiple applications. 

The cluster controller 26 might also include at least one storage drive— such as a 
CD ROM drive, PC Card drive, or a floppy disk drive— which permits use of portable 

10 storage media. A CD ROM drive enables application-related CDs, as well as musical, 
video, game, or other types of entertainment CDs. The cluster controller 26 is 
constructed and sized to mount in the dashboard of the vehicle. A detailed explanation of 
one suitable construction of a cluster controller is described in U.S. Patent No. 5,794,164, 
entitled "Vehicle Computer System," which issued August 11, 1998, in the names of 

15 Richard D. Beckert, Mark M. Moeller, and William Wong. This application is assigned 
to Microsoft Corporation and is hereby incorporated by reference. 

The SCU 26 maintains an up-to-date copy of executable code 1 12 run by the MCU 
24 to manage data flow among the components. The MCU code 1 12 is downloaded to 
the SCU 26 during initialization and stored in the non-volatile memory 104. In the event 

20 that the MCU 24 fails, the secondary control unit 26 executes the MCU code 112 to 
assume the master responsibility of data flow management on the primary bus 28. 

Cluster Contro ller Software Architecture 

Fig. 5 shows the software architecture 118 employed in the cluster controller 26. 
25 The cluster controller architecture 1 1 8 has an application layer supported by an operating 
system and an underlying hardware layer. 
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Four applications are shown in the application layer. A CD (compact disk) 
application 120 operates a CD player and a radio application 122 controls AM/FM radio 
functionality. A navigation application 124 utilizes the navigation and GPS components 
42 and 44, and a phone application 126 operates the communications module 46. 
5 The operating system 1 10 contains a shell 128, application programming interfaces 

(APIs) 130-136, a kernel 138, device driver interfaces (DDIs) 140-144, and a hardware 

abstraction layer (HAL) 146. 

The APIs 130-136 define the interfaces to the system platform that are available 
the application programs 120-126. Each API provides a common and consistent set of 
10 interfaces for applications development and provides access for the applications 120-126 
to advanced features of the operating system. In this illustration, an audio API 130 
provides interfaces for the CD application 120 and radio application 122. Navigation API 
132 provides interfaces for the navigation application 124 and a telephony API 134 
provides interfaces for the phone application 126. A tuner API 136 provides interfaces 
1 5 for the radio applications 122. 

The kernel 138 provides the base operating system functionality. It is responsible 
for memory management, process management, and certain required file management 
functions. More specifically, the kernel manages virtual memory, scheduling, 
multitasking, multithreading, and exception handling. 
20 The device driver interfaces (DDIs) 140-144 expose the services of a peripheral 

device to the kernel and applications. A well-defined set of DDIs allows different device 
drivers to look alike to the operating system and application software, removing the need 
to specifically tailor the operating system or application software to the device it 
communicates with. Here, a display driver 140 provides interfaces to a display (e.g., 
25 monitor, LCD), a disk driver 142 provides interfaces to the memory disk drive peripheral, 
and a USB (universal serial bus) driver 144 provides interfaces for a USB bus 148. 



WO 00/07849 PCT/US99/16310 

12 

A hardware abstraction layer (HAL) 146 is a thin layer of code that provides the 
interface between the kernel and the device hardware. Its goal is to provide software that 
allows a device driver to support the same device on all hardware platforms. This allows 
variations in hardware platforms (using different processor) without requiring a separate 
5 version of the operating system for each one. 

The cluster controller architecture 118 of Fig. 5 is specifically tailored for an in- 
vehicle multimedia information and communication system. This architecture provides 
an example of how cluster controller 26(2) might be configured to run cluster 66 (Fig. 3). 
The cluster controller architecture 118 incorporate the functions of a radio, CD player, 
10 navigation, address book, paging, email, cellular phone, as well as a user-friendly display. 
The in-vehicle entertainment and information system is built on the flexible operating 
system 1 10 with common interfaces to enable developers to develop multiple devices and 
applications, without having to tailor these developments to a specific hardware platform 
or processor. 

15 Alternatively, cluster controller 26(1) that is governs cluster 64 in Fig. 3 might be 

configured to run different applications and interface with different hardware 
components. For example, cluster controller 26(1) might support applications pertaining 
to wipers, power door locks and seat controls, and the HAL 146 and DDIs provide 
interfaces for the wiper peripheral device, the door locks module, and the seat module. 

20 

Conclusion 

The cluster architecture, with an open system OS platform-based controller at its 
core, allows construction of a vehicle information system that can handle multiple 
devices, run multiple applications, and permit communications among the devices. The 
25 devices can range from simple sensors and actuators or some semi-intelligent devices 
such as the entry control system, to intelligent devices such as a digital signal processor. 
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The information flow is managed over common buses, with standard protocols, rather 
than dedicated wiring and specialized protocols. 

Although the invention has been described in language specific to structural 
features and/or methodological steps, it is to be understood that the invention defined in 
5 the appended claims is not necessarily limited to the specific features or steps described. 
Rather, the specific features and steps are disclosed as preferred forms of implementing 
the claimed invention. 
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CLAIMS 

1. An automobile information system comprising: 
a data communications bus; 

multiple components connected to the data communications bus; and 
5 a cluster controller to manage information among the components. 

2. An automobile information system as recited in claim 1, wherein the cluster 
controller comprises a general-purpose computer with an open platform operating system. 

10 3. An automobile information system as recited in claim 1, wherein the cluster 

controller receives information from an external source and shares the information with 
the components. 

4. An automobile information system as recited in claim 1, wherein the cluster 
1 5 controller facilitates information flow between at least two of the components. 

5. An automobile information system as recited in claim 1, wherein the 
multiple components are selected from a group of components comprising a climate 
control component, a lighting component, a windshield wipers component, a door lock 

20 component, and a power window component. 

6. An automobile information system as recited in claim 1, wherein the 
multiple components are selected from a group of components comprising an audio 
component, a navigation component, and a communications component. 

25 



10 
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7. An automobile comprising an automobile information system as recited in 
claim 1. 

8. An automobile information system comprising: 
a data communications bus; 

multiple components connected to the data communications bus; and 
a cluster controller having an open platform, multitasking operating system to 
support multiple applications and provide interfaces to the multiple components. 

9. An automobile comprising an automobile information system as recited in 
claim 8. 



10. An automobile information system comprising: 

first and second data communications buses; 
1 5 a first cluster of components connected to the first data communications bus; 

a first cluster controller connected to the first data communications bus to manage 
information among the first cluster of components; 

a second cluster of components connected to the second data communications bus; 

a second cluster controller connected to the second data communications bus to 
20 manage information among the second cluster of components; and 

a third data communications bus to interconnect the first and second cluster 
controllers. 



11. An automobile information system as recited in claim 10, wherein the first 
25 and second cluster controllers are each configured as general-purpose computers open 
platform operating systems. 
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12. An automobile information system as recited in claim 10, wherein the first 
and second data communications buses are a same bus. 

13. An automobile information system as recited in claim 10, wherein 
5 communication between a component in the first cluster and a component in the second 

cluster is facilitated via the first and second cluster controllers. 

14. An automobile information system as recited in claim 10, wherein the first 
cluster of components comprises components selected from a group of components 

10 comprising a climate control component, a lighting component, a windshield wipers 
component, a door lock component, and a power window component. 

15. An automobile information system as recited in claim 10, wherein the 
second cluster of components comprises components selected from a group of 

15 components comprising an audio component, a navigation component, and a 
communications component. 



16. 

claim 10. 



An automobile comprising an automobile information system as recited in 
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